fix(store): allocate graph id before batch writes - #3153

Overview

Closes #3095. This PR extracts the focused fix from hugegraph#163.

Physical key layout

┌──────────────────┬──────────────────────┬──────────────────┐
│ GraphId · 2 bytes │ Logical key          │ Key code · 2 bytes │
└──────────────────┴──────────────────────┴──────────────────┘

The GraphId prefix is what keeps data from different graphs in separate physical ranges:

65534 (0xFFFE) is reserved for a missing GraphId mapping. The old batch path called getKey(), which returned this sentinel instead of allocating an ID.

Trigger conditions

The collision requires all three conditions:

Once multiple graphs meet these conditions in the same partition, they share the FFFE prefix.

Data impact

Fix

The first-allocation path also checks whether the vertex table exists before scanning it. This avoids upgrading the column-family read lock held by the prepared batch into a write path that creates the missing table.

Regression coverage

BatchGraphIsolationTest exercises the real BusinessHandler.doBatch() and RocksDB path:

• distinct PUT values for the same logical key in two graphs;
• target-graph deletion and neighboring-graph preservation after truncate;
• isolated MERGE counters;
• first batch write on an empty partition without creating the vertex table;
• rollback of failed transfer batches;
• truncate waiting for an in-flight batch transaction.

mvn test -pl hugegraph-store/hg-store-test -am \
    -P store-core-test -Djacoco.skip=true -ntp

Scope

This focused change keeps the physical-key format, public APIs, dependencies, configuration, and CI workflow unchanged. It does not repair already affected data or include broader GraphId lifecycle, ID-reuse, or historical-data migration work.

PR checklist

• Regression coverage added and verified
• No dependency or configuration changes
• No public API changes
• Documentation update not required